Please note that SIGPIPE might be also a result from operations on sockets (sent, sendto, sendmsg could also return EPIPE and generate SIGPIPE signal):

@nalajcie if we add such wrapper for send, sendto and sendmsg will this be ok? It's a simple solution and fits nicely in our architecture, question is - is it enough?

I've found some more insights:
https://riptutorial.com/posix/example/17424/handle-sigpipe-generated-by-write---in-a-thread-safe-manner

Seems that on MacOS / BSD there is a socket option (SO_NOSIGPIPE) to disable signals for particular socket which would impair the current approach (You would need to call additional syscall for each write()). On Linux tere is MSG_DONTWAIT flag for send / sendmsg (and socket option is not supported) so this approach might be good enough - we probably need to decide which API we would like to support. The current approach doesn't sit well with me because of additional syscall which in kernel would be a no-op (most complex programs will have SIGPIPE ignored) - but I agree that it fits with our current approach.

On a side note - it's written in the link provided that POSIX-2004 requires us to send signal to the correct thread (not process) which is something we should take into the consideration in the future.

@nalajcie About sending signal to the right thread - our raise already does this - it send a signal specifically to the thread that called raise, so we're covered here. It is required by POSIX for raise to behave this way anyway.

@nalajcie About sending signal to the right thread - our raise already does this - it send a signal specifically to the thread that called raise, so we're covered here. It is required by POSIX for raise to behave this way anyway.

Oh, that's great! I don't know how advanced our signal implementation is, do we support per-thread signal masking also (phtread_sigmask as in https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_sigmask.html)?